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METHODE D'AUTHENTIFICATION D'APPUCATIONS 

La presente invention conceme le domaine des reseaux mobiles appeles aussi 
reseaux cellulaires. Elle conceme plus particulierement la gestion de la securite 
duplications mise en ceuvre avec un module de securite associe a un equipement 
5 mobile de telephonie mobile. 

Le module de securite d v un telephone mobile ou portable est connu sous 
I'appellation "carte SIM" (Subscriber Identity Module) constituent I'element central 
de la securite de ces telephones. L'operateur de telephonie introduit, a la fabrication 
et/ou lors d'une phase de personnalisation, un numero appele IMSI (International 

1 0 Mobile Subscriber Identification) servant a identifier d'une manidre sQre et unique 
chaque abonne desirant se connecter sur un reseau mobile. Chaque telephone 
mobile, appel6 Equipement mobile ci-aprSs, est identifie physiquement par un 
numero stocks dans une memoire non volatile de I'equipement mobile. Ce numero, 
appele IMEI, (International Mobile Equipment Identifier) content une identification 

15 du type d'equipement mobile et un numero de serie servant a identifier de maniere 
unique un equipement mobile donne sur un reseau du type GSM (Global System for 
Mobile communications), GPRS (General Packet Radio System) ou UMTS 
(Universal Mobile Telecommunications System). De plus, un equipement mobile est 
caract6ris6 par une version de logiciel SVN (Software Version Number) indiquant 

20 I'etat de mise & jour du logiciel de base installe sur I'equipement mobile. La 
combinaison de ^identification du type et du numero de serie de I'equipement 
mobile avec la version de logiciel (SVN) donne une nouvelte identification, appel6e 
IMEISV (International Mobile Equipment Identifier and Software Version Number). 
Le meme concept ^identification s'applique dgalement au WLAN (Wireless LAN) ou 

25 au cable TV bidirectionnel. L'ident'rfiant physique peut §tre une adresse MAC (Media 
Access Control) qui correspond £ I'adresse unique identifiant la configuration du 
materiel d'un utilisateur sur un reseau IP (Internet Protocol) et la version de logiciel 
peut etre transmise par des protocoles de couche sup^rieure bases sur IP. 

Les normes ETSI ("European Telecommunications Standards Institute"), definissent 
30 une station mobile (MS, mobile station) composee d'un equipement mobile (ME, 
mobile equipment) et d'un module d'abonne (SIM, subscriber identity module). Ce 
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module d'abonne est en general amovible c'est-^-dire qu'il peut etre soit retire soit 
transferee d'un equipement mobile a un autre. 

Lors de la mise en sen/ice d'un equipement mobile, plus particulierement lors de sa 
connexion au reseau d'un operateur, des informations comprenant les donnSes 
5 ^identification sont echang6es entre I'equipement mobile et le centre de gestion de 
I'opSrateur qui autorise ou non son utilisation. Actuellement un equipement mobile 
offre a Putilisateur, en plus de sa fbnction usuelie d'etablissement de conversations 
t6lephoniques par !e biais d'un acces a un reseau mobile, I'utilisation de nombreux 
autres services supplementaires a valeur ajoutde tels que ia consultation de 
10 diverses informations, les operations bancaires & distance, le commerce 
electronique, I'acces a du contenu multimedia, etc. Ces services evolues 
necessitent un niveau de securite de plus en plus eleve afin de premunir les 
utilisateurs centre les fraudes eventuelles causees par des tiers cherchant a 
exploiter des failles de s6curit6 qui peuvent apparaTtre sur les equipements mobiles. 

15 Une verification devient done n6cessaire au moins a deux niveaux: d'une part au 
niveau de I'equipement mobile lui-meme et d'autre part a celui des applications 
logicielles permettant le fonctionnement des diffdrents services proposes par 
I'operateur ou des parties tierces. Ces applications sont en general telechargees 
depuis le serveur d'un foumisseur duplications, ce qui implique la n6cessite de 

20 verifier ce t6l6chargement. II s'agit done de garantir que le module d'abonne ne 
fournit des informations qu'd des applications autoris6es une fois que ce module a 
ete reconnu par le serveur de contrdle comma pouvant fonctionner avec 
P6quipement mobile dans lequet il est insere. 

Le module d'abonne peut contenir des informations confidentielles tels qu'un 
25 num^ro de compte bancaire ou un mot de passe. Une application fonctionnant sur 
I'equipement mobile sera en charge d'utiliser ces donnees personnelles afin de 
fournir le service attendu. Neanmoins, une application pourrait d6tourner ces 
donnees personnelles a d'autres fins que le dialogue avec le foumisseur 
d'application concerne. II peut en resulter un prejudice important pour le propri6taire 
30 du module d'abonng. 
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Ces applications exScutees dans I'equipement mobile utilisent des ressources 
disponibles dans le module d'abonne. Par ressources, on entend diverses fonctions 
et donn6es n6cessaires au bon fonctionnement d'une application. Certaines de ces 
ressources peuvent etre communes a plusieurs applications, notamment les 
5 fonctions Ii6es k la s6curit6. Le module d'abonn6 peut ainsi bloquer ou alt6rer le 
fonctionnement de certaines applications pour lesquelles les conditions de security 
etablies par Toperateur et/ou les foumisseurs duplications ne sont pas respect6es 
dans I'equipement mobile en question ou les droits de I'utilisateur de I'equipement 
mobile sont insuffisants. 

10 Le document FR2831362 decrit un precede de transaction s6curisee entre un 
telephone mobile muni d'une carte SIM et un serveur duplications. Le but de ce 
precede est de proteger des droits lies a ['utilisation duplications telechargees 
depuis le serveur au moyen de la carte SIM. 

Selon ce proc£d£, un lien de confiance est d'abord 6tabli entre le serveur et la carte 
15 SIM par I'echange securise de cles publiques, puis un achat d'une application est 
effectue par la transmission d'un fichier de demande par I'equipement mobile au 
serveur. Celui-ci encrypte partiellement ou entierement I'application et transmet a 
I'equipement mobile un cryptogramme forme par la cle d'encryption et une 
commando, le tout crypt§ avec une cle publique connue de la carte SIM. A la 
20 reception par I'equipement mobile, ce cryptogramme est decrypte et la cle stockee 
dans la carte SIM. L'ex6cution de la commando entraTne le t6!6chargement dans 
I'equipement mobile de I'application partiellement ou entierement encryptee par le 
serveur. Une fois chargee, I'application est decryptee par la cl6 stock6e dans la 
carte SIM puis installee dans I'equipement mobile. 

25 Selon ce precede, les droits d'utiliser I'application dans I'equipement mobile sont 
proteges du fait du lien de confiance etabli inrtialement entre i'equipement et le 
serveur et precedant la transaction. Le role joue par le serveur se concentre ici 
plutot dans la gestion des droits ou DRM (Digital Rights Management) des 
utilisateurs d'une application dans un equipement mobile. La solution developpee ci- 

30 apres est orientee plutot vers la gestion des risques (Risk Management) pris en 
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compte par I'opgrateur, le foumisseur d'application ou I'utilisateur par rapport d una 
application. 

Le but de la presente invention est de proposer une methode d'authentification de 
ou des applications dans un gquipement mobile tant lors de leur telechargement 
que lors de leur execution. II s'ag'rt de limiter les risques lies au fait qu'un module 
d'abonne soit utilise a mauvais escient soit par des applications ne remplissant pas 
certains criteres de securite, soit par des equipements mobiles ne remplissant pas 
certains criteres de securite preetablis. 

Un autre but est de proteger I'utilisateur de I'equipement mobile ainsi que les 
foumisseurs d'applications concernes contre les abus resultants de I'usage 
d'applications non autorisees. 

Ces buts sont atteints par une methode d'authentification d'au moins une application 
fonctionnant dans un 6quipement connects par un r6seau d un serveur de contrfiie, 
ledit equipement etant localement connecte a un module de securite, ladite 
application est chargee et/ou executee au moyen d'un environnement d'ex^cution 
d'applications de I'equipement et utilise des ressources stockees dans le module de 
s£curite, comprenant les etapes preliminaires suivantes: 

- reception de donnees comprenant au moins Tidentifiant de I'equipement et 
Tidentifiant du module de securite, via le reseau, par le serveur de oontrdle, 

- analyse et verification par le serveur de controle desdites donnees, 

- generation d'un cryptogramme comprenant une empreinte de Tapplication, des 
donnees identifiant I'equipement et le module de securite et des instructions 
destinees audit module, 

transmission dudit cryptogramme, via le reseau et I'equipement, au module de 
securite, 

verification de I'application en comparant I'empreinte extrarte du cryptogramme 
regu avec une empreinte determinee par le module de securite, 
ladite mdthode est caract6ris6e en ce que, lors de I'initialisation et/ou de Tactivation 
de I'application, le module de securite execute les instructions extraites du 
cryptogramme et libfere, respectivement bloque I'acc&s d certaines ressources dudit 
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module de s6curitG en fonction du r6sultat de la verification propre £ cette 
application effectuee prealablement. 

Les ressources du module de security sont bloquees ou liberees de maniere ciblee, 
ceci dans le but de rendre certaines applications utilisables ou non. On ne bloque 
pas ou libere pas directernent des applications de I'equipement mobile: on agrt de 
maniere indirecte sur les applications, c'est-a-dire que I'effet de blocage ou de 
liberation va se manifester uniquement lorsque I'equipement mobile essaiera 
d'executer ces applications. 

Cette methode s'applique de preference au reseau mobile. Par consequent, 
l^quipement est, par exemple, un equipement de telSphonie mobile et le module de 
sicurite un module d'abonne ou carte SIM. Cet ensemble se connecte a un reseau 
mobile du type GSM (Global System for Mobile communications), GPRS (General 
Packet Radio Service), UMTS (Universal Mobile Telecommunications System) ou 
autre, gere par un serveur de contrdle d'un operateur. Des applications logicielles 
sont installees dans I'equipement mobile et configures de maniere a utiliser des 
ressources (donnees ou fonctions) presentes dans le module d'abonne. Elles ne 
peuvent done dtre utilisdes dans leur integrality seulement si les conditions de 
securites sont satisfaites selon des criteres pr6etablis par I'operateur et/ou le 
fournisseur duplications. Cette verification des crttdres est d la charge du serveur 
de contrdle. (.'application, suite aux instructions envoyees par le serveur de 
controle, est finalement a la charge du module de sgcurite qui peut laisser libra ou 
bloquer racces a des ressources necessaires au bon fonctionnement d'une 
application installee dans Tequipement mobile. 

Les donnees de ces ressources peuvent comprendre des informations tels que 
num§ro de comptes, des programmes (sous forme de code pouvant etre installe 
dans i'equipement mobile), des cles d'encryption/decryption, des droits d'acces d du 
contenu, etc. 

Les fonctions de ces ressources peuvent comprendre des algorithmes 
cryptographiques, des processus de verification, des processus de generation de 
signatures digitales, des processus d'encryptage, des processus d'authentlfication, 
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des processus de validation de donnges, des processus de contrdle d'acc&s, des 
processus de sauvegande de donnees, des processus de paiement etc. 

La m6thode selon I'invention est basee sur le fait qu'a une application on associe un 
cryptogramme qui conditionne I'utilisation de I'application sur un 6quipement mobile 
connecte a un reseau. 

A la difference du proced6 decrit dans le document FR2831362, ['encryption 
partielle ou entiere de Tapplication, avant tel§chargement dans l'6quipement mobile, 
n'est pas necessaire. En effet, selon la methode de I'invention, la liaison entre le 
serveur et le module de securite (ou module d'abonne) sert a controler de maniere 
optirnale ses ressources et a decider leur mise en service ou non par rapport aux 
applications executees dans I'equipement mobile. La commande regue du serveur, 
dans le proc6d6 du document cite, permet de controler I'utilisation de I'application 
installee dans I'equipement mobile, tandis que dans la pr6sente m6thode, elle 
permet d'activer ou desactiver des ressources du module de s6curit6. 

Par exemple, lorsque des ressources sont desactiv6es, Tappllcation fonctionnera 
d'une fagon "minimale" laissant un nombre nSduit de possibil*rt6s a I'utilisateur. Dans 
un exemple de realisation, cette reduction peut porter sur le montant maximum 
autoris6 pour I'achat de services et de plus, ces services ne pourraient etre obtenus 
que dans un lieu donne (centre commercial, stade, gare, aeroport, etc.) 

Dans un premier mode de realisation, le cryptogramme est transmis au module 
d'abonne pendant le changement de I'application. Dans un second mode de 
realisation, c'est I'application qui va chercher le cryptogramme sur le serveur de 
controle lors de sa premiere utilisation. 

La methode d'authentification sefon I'invention s'applique egalement lors de 
I'exdcutlon d'une application par I'equipement mobile, ce qui permet de s'assurer, a 
I'aide du module d'abonne, que cette application est autorisee a acceder certaines 
ressources (donn6es ou fonctions) contenues dans ledit module d'abonne. En 
particulier, le module d'abonne peut verifier regulierement le cryptogramme attache 
d une application au cours de I'execution de ladite application. 
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Par exemple, I'insertion d'un module d'abonne d'un utilisateur dans un autre 
equipement mobile influencera le fonctionnement de certaines applications sans 
empecher I'etablissement de communications telephoniques classlques. Cette 
barriere agit en quelque sorte comme un filtre visant a eliminer des equipements 
5 mobiles non autorises ou encore des applications provenant de sources non 
agreees par I'operateur ou un foumisseur d'application partenaire. 

Une modification de ^application par un tiers est egalement detectee par le module 
d'abonne qui refusera d'executer certaines commandes regues entratnant ainsi le 
blocage ou des limitations de I'execution de ('application. 

10 Le serveur de contrdle joue done un role essentiel en gerant les elements de 
confiance ou de securite lies a I'ensemble equipement mobile/module d'abonne. II 
interpr&te les donn6es qui lui sont transmises par l'6quipement mobile afin de 
controler ou limiter ('utilisation d'applications grace aux ressources (donnees ou 
fonctions) stockees dans le module d'abonne. 

15 Le serveur recevant les informations d'identite d'un equipement mobile et de son 
module d'abonne et comprenant les identifiants IMEISV et I'IMSI decide, selon 
certains cnteres, si une nouvelle instruction doit etre envoyee au module d'abonn§ 
pour red6finir un nouveau profil de protection definissant les ressources du module 
d'abonne pouvant etre utilisees par les applications executees dans I'equipement 

20 mobile. Les critdres peuvent se r6f6rer, par exemple, d la mise d jour de la version 
de logiciel installee sur I'equipement mobile, au teiechargement de nouvelles 
applications sur i'equipement mobile, a la periode de mise a jour du profil de 
protection, au nombre de connexions au reseau, a la technologie utilisee pour 
Tacces au reseau, a IMdentite du reseau d'acces utilise, lis sont egalement lies a 

25 diff^rents risques associes au materiel ou aux logiciels utilises que Toperateur et/ou 
le foumisseur d'applications et/ou Tutilisateur de I'equipement mobile desirent 
prendre en compte. 

La verification du cryptogramme peut s'effectuer lors du premier d6manrage ou lors 
de la premiere utilisation d'une application ou a chaque demarrage de celle-ci. 
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Selon une variante, elle peut §tre ex£cut6e p6riodiquement d un rylhme donne 
selon des instructions provenant du serveurde controle. 

Lors d'un chargement d'une application dans un gquipement mobile, le 
cryptogramme attache accompagnant 1'application inclut en g6n6ral une empreinte 
de I'application elle-meme, c'est a dire un bloc de donnees calcule a partir du code 
de ('application a I'aide d'une fonction mathematique unidirectionnelle de hachage. 

Lorsque le module d'abonne verifie la validity du cryptogramme, il identifie aussi, de 
maniere indirecte, l'6quipement mobile et s'assure que les donnees viennent 
effectivernent du serveur de controle. Autrement dit, par ce cryptogramme, le 
serveur de controle donne implicitement I'assurance au module d'abonne que le 
type et la version de logiciel de l'6quipement mobile ont ete pris en compte, que le 
chargement de I'application a et§ controle et que I'application est authentique. Selon 
des instructions prealablement regues, le module d'abonne decidera d'autoriser ou 
de refuser des requetes ou des commandes venant de I'application. 

L'€quipement mobile joue un role de relais dans cette etape de verification en 
etablissant un dialogue quasi direct entre le module d'abonne et le serveur de 
controle. Ainsi la securite des messages echanges est assuree de bout en bout 
entre le serveur de controle et le module d'abonne via I'environnement d'execution 
des applications de Tequipement mobile. Celui-ci ne peut done pas "tricher" ou 
transformer les donnees vis-d-vis du module d'abonnd. 

La presente invention concerne egalement un module de s6curit6 comprenant des 
ressources destinees a etre localement accedees par au moins une application 
installee dans un equipement relie a un reseau, ledit equipement comprenant des 
moyens de lecture et de transmission de donnees comprenant au moins I'identifiant 
de I'equipement et i'identifiant du module de securite, ledit module est caracterise 
en ce qu'il comprend des moyens de reception, de stockage et d'analyse d'un 
cryptogramme contenant entre autre donnees une empreinte de ladite application et 
des instructions, des moyens de verification de ladite application et des moyens 
d'extraction et d'execution des instructions contenues dans le cryptogramme liberant 
ou bloquant certaines ressources selon le rSsultat de la verification de I'application. 



WO 2005/053263 PCT/EP2004/053116 

-9- 

Ce module de s6curite est utilise par exemple comme module d'abonn6 ou carte 
SIM connecte £ un equipement mobile. 

L'invention sera mieux comprise grace a la description detaillee qui va suivre et qui 
se refere aux figures annexees donn6es a titre d'exemple nullement limitatif, £ 
5 savoir: 

- La figure 1a illustre un schema bloc montrant le processus d'installation d'une 
application selon un premier mode de realisation ou le cryptogramme est delivre via 
I'environnement d'execution d'applications. 

- La figure 1 b illustre le processus de verification du cryptogramme selon le mode de 
10 la figure 1a. 

- La figure 1c illustre le processus de I'execution de I'application utilisant les 
ressources du module d'abonnd selon le mode de la figure 1a. 

- La figure 2a illustre un schema bloc montrant le processus d'installation d'une 
application selon un second mode ou Implication seule est telechargee. 

15 - La figure 2b illustre le processus de verification ou 1'application sollicite un 
cryptogramme aupres du serveur de controle selon le mode de la figure 2a. 

- La figure 2c illustre le processus de I'execution de I'application utilisant les 
ressources du module d'abonn6 selon le mode de la figure 2a. 

- La figure 3a illustre un schema bloc montrant le processus d'installation d'une 
20 application selon un troisieme mode ou I'application seule est telechargee. 

La figure 3b illustre le processus de verification ou I'application sollicite un 
cryptogramme et une empreinte de i'application aupres du serveur de controle selon 
le mode de la figure 3a. 

La figure 3c illustre le processus de rexecution de I'application utilisant les 
25 ressources du module d'abonne selon le mode de la figure 3a. 

- La figure 4 illustre la structure d'un exemple de cryptogramme. 
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Les schemas blocs des figures 1a, 1b, 1c, 2a, 2b, 2c, 3a, 3b, 3c montrent un 
ensemble equipement mobile (CB) module d'abonne (SIM) contenant des 
ressources (RES) relie via un reseau mobile (NET) a un serveur de contrdle (CSE) 
administre par un operateur. Ce serveur (CSE) est connecte a un ou plusieurs 
foumisseurs d'applications (FA). 

L'equipement mobile (CB) inclut une ou plusieurs applications (APP) logicielles 
fonctionnant dans un environnement d'execution (AEE). Ces applications (APP) 
proviennent, soit du foumisseur d'applications (FA) associe au serveur de contrdle 
(CSE) de I'operateur, soft, elles peuvent etre programmees d'origine par le fabricant 
de l'equipement mobile (CB). Dans ce dernier cas, il est parfois nScessaire de 
telecharger des mises a jour qui sont egalement verifiees par le module d'abonne 
(SIM). 

Selon le premier mode de realisation illustre par les figures 1a, 1b, 1c, le 
cryptogramme (CRY) d'une application (APP) est delivre au module d'abonne (SIM) 
via I'environnement d'execution d'applications (AEE) lors du processus d'installation 
de I'application (APP). 

La figure 1a illustre le processus d'installation ou l'equipement mobile (CB) transmet 
d'abord des donnees servant a I'identification (ID) du module d'abonne (SIM) que le 
serveur de contrdle (CSE) verifie. Cette identification (ID) est effectuee a partir de 
I'identifiant (IMSI) du module d'abonne (SIM) et de I'iderttifiant (IMEISV) unique de 
l'equipement mobile (CB). Une application (APP) est ensuite telechargee depuis le 
serveur (CSE) accompagnee d'un cryptogramme (CRY) qui sera transmis vers le 
module d'abonne (SIM) via I'environnement d'execution (AEE) pour verification 
comme illustre dans la figure 1b. 

II est a noter que le foumisseur (FA) est considere comme digne de confiance par 
I'operateur, c'est-a-dire que les applications (APP) sont homologuees et 
fonctionnent sans causer un quelconque prejudice § i'utilisateur et/ou a I'operateur. 

La methode selon I'invention s'applique a plusieurs formes d'applications (APP) 
executees dans difFerents types d'environnement d'execution (AEE). Par exemple, 
de nombreux telephones mobiles possedent des fonctionnalites issues 
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cTappIications Java qui sont executees par une machine vlrtuelle (VM) Java servant 
de processeur et d'environnement La description ci-aprds se base sur I'exemple 
d'applications Java. Bien entendu, d'autres environnements ou systemes 
d'explortations tels que Symbian OS, Windows, Palm OS, Linux etc. peuvent etre 
utilises comme support d'applications. 

Lors de son execution, voir figure 1c, une application Java sollicite le module 
d'abonne (SIM), elle en informe I'environnement d'execution (AEE) en lui adressant 
des requetes ou commandes (CMD). L'environnement d'execution (AEE) calcule 
I'empreinte (FIN2) de I'application (APP) et I'envoie au module d'abonne (SIM). Le 
cryptogramme (CRY) qui a ete genere par le serveur de controle (CSE) puis charge 
dans l'6quipement mobile (CB) avec ('application (APP) (ou separement), est stocke 
dans le module d'abonne (SIM). Ce dernier verifie d'abord qu'il possede 
effectivement les donnges n6cessaires lui permettant de decider s'il doit r6pondre d 
des requetes ou commandes (CMD) de Implication (APP). Ces donnees, faisant 
office de droits charges a partir du serveur de controle (CSE) lors du chargement de 
I'application (APP), permettent de controler le fonctionnement de I'application (APP). 
En cas d'absence de ces droits, I'application (APP) ne pourra utiliser les ressources 
(RES) (donnees ou fonctions) du module d'abonne (SIM). 

Dans le cas ou ces droits sont presents, le module d'abonne (SIM) verifie 
rempreinte (FIN1) issue du cryptogramme (CRY) stocke en la comparant avec 
I'empreinte (FIN2) associ6e d I'application (APP) et foumie par I'envlronnement 
d'application (AEE). Ce cryptogramme (CRY) petit se constituer sous la forme d'un 
bloc encrypte par une cle privee du type RSA (Rivest, Shamir, Adelman). Ce bloc 
represents par la figure 4 contient par exemple, entre autres donnees, Tidentifiant 
IMSI (ID„SIM) du module (SIM) d'abonne, Hdentifiant IMEISV (ID_CB) de 
l'6quipement mobile (CB), un identificateur (ID_APP) de I'application, I'empreinte 
(FIN1) de I'application (APP), des identificateurs SIM (RESJD) des ressources 
(RES) et des Instructions (INSURES) de blocage/lib6ration des ressources SIM. 
Cette cle privee ne serart connue que du serveur de controle (CSE), alors que sa 
partie publique serart connue du module d'abonng (SIM). L'avantage de ('utilisation 
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de cl6s asym6triques reside en ce que la cl6 servant d cr6er des cryptogrammes ne 
se trouve pas a I'exterieur du serveur de controle (CSE). 

Bien entendu, d'autres algorithmes a cles asymetriques tels que par exemple DSA 
(Digital Signature Algorithm), et ECC (Elliptic Curve Cryptography) peuvent 
constituer des alternatives a RSA 

L'usage d'algorithme a cles symetriques peut etre prefere pour des raisons de 
simplicity, de rapidity des verifications ou de coQts de fabrication et de mise en 
oeuvre plus faibles. Dans ce cas, la cle serait connue du serveur (CSE) et du 
module d'abonn6 (SIM), par exemple un algorithme IDEA (International Data 
Encryption Algorithm) pourrait §tre utilise pour signer le bloc (IMSI, IMEISV, 
identificateur de ('application, empreinte de Implication, identificateurs des 
ressources SIM, instructions de blocage/liberation des ressources SIM). Comme 
alternative a I'algorithme IDEA, des algorithmes tels que, par exemple, TDES (Triple 
Data Encryption Standard) et AES (Advanced Encryption Standard) peuvent aussi 
etre utilises. 

Dans ces deux variantes a cI6s asymetriques et symetriques, le module d'abonne 
(SIM) verifie la concordance des diffe rents champs apparaissant dans le 
cryptogramme (CRY), notamment il controle les identificateurs duplications 
(ID_APP) et les empreintes duplications (FIN1) qui sont autorisees ou non a 
utiliser ses ressources (RES) (donn6es ou fonctions). 

Dans une variante, le cryptogramme (CRY) peut inclure un compteur servant d 
empecher le double usage d'un meme cryptogramme adresse au module d'abonne 
(SIM) (replay attack). En effet deux applications du meme type peuvent porter le 
meme identificateur et avoir la meme empreinte (FIN1). Dans ce cas, le module 
d'abonne (SIM) controlera aussi la valeur de ce compteur par comparaison avec 
cells d f un compteur de reference stocke et regulierement mis a jour. 

Une variante au compteur est d'utiliser un alea (nombre aleatoire) genere par le 
module d'abonne (SIM). Cet alea est transmis avec les donnees envoyees au 
serveur de controle (CSE). Ce dernier renvoie cet alea dans le message de reponse 
et le module d'abonne (SIM) peut verifier qu'il s'agit bien d'un nouveau message. 
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Plus g§n6ralement, afin d'6viter tout risque d'usage d'un ancien cryptogramme 
(CRY), cette demiere comprend une variable pr6dictible par le module d'abonn<§ 
(SIM), soit un compteur ou un al6a. 

Dans une autre variante le cryptogramme (CRY) gener§ a I'aide d'une cle du type 
5 RSA ou IDEA peut etre remplacee par un bloc gSnere avec une cle partagee HMAC 
(Keyed-Hashing for Message Authentication) a partlr de i'ensemble (IMSI, IMEISV, 
identificateur de i'application, empreinte de I'application, identificateurs des 
ressources SIM, instructions de blocage/lib6ration des ressources SIM). HMAC est 
un mecanisme pour rauthentification de messages par rutilisation de fonctions de 
10 hachage cryptographiques telles que MD5 (Message Digest) ou SHA-1 (Secure 
Hash Algorithm), en combinaison avec une cle partagee. 

Cette cle prdsente a la fois dans le serveur de controle (CSE) et dans le module 
d'abonni (SIM) peut etre chargee lors de la personnalisation du module d'abonne 
(SIM) ou lors de ('installation de certaines ressources (RES) dans le module 
15 d'abonne (SIM). Selon les options, a chaque ressource (RES) ou groupe de 
ressources du module d'abonn6 (SIM) peut ©tre associ6e une c!6 diff6rente f ou 
bien, la cl£ peut etre globale pour I'ensemble des ressources (RES) et unique pour 
un module d'abonne (SIM) donne. 

Le cryptogramme (CRY) permet ainsi au module d'abonne (SIM) de connaTtre la ou 
20 les ressources (RES) pouvant etre liberees ou bloquees dans le module d'abonne 
(SIM) pour I'equipement mobile (CB) correspondent. 

Les deux empreintes Lrtilisees (FIN1, respectivement FIN2) sont des elements 
determinants car elles constituent un moyen de controle cryptographique de 
I'application (APP) par I'equipement mobile (CB) et par le module d'abonne (SIM). 
25 Un tel controle est necessaire afin d'empecher qu'une application tierce s'authentifie 
avec un cryptogramme (CRY) donne. En eflet, si le cryptogramme A authentifie 
I'application A aupres du module d'abonne A dans un equipement mobile A, il faut 
6viter qu'une autre application B s'authentifie indument avec ce meme 
cryptogramme A aupres du module d'abonne A dans I'equipement mobile A. 
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Selon une variante, I'empreinte de 1'application (FIN1) incluse dans le cryptogramme 
(CRY) reste confidentielle de bout en bout entre ie serveur de controle (CSE) et le 
module d'abonne (SIM). Pour ce faire I'empreinte (FIN1) est encrypt6e par le 
serveur de controle (CSE) et decryptee par le module d'abonne (SIM). De plus, 
Implication (APP) peut ©tre personnalis6e pour un chargement donn6 de manfere £ 
ce que I'empreinte (FIN1) incluse dans le cryptogramme (CRY) et I'empreinte (FIN2) 
de I'application (APP) calculee par I'environnement d'execution (AEE) restent 
identiques mais dependent de I'identite de I'equipement mobile (CB). Une telle 
mesure est necessaire si Ton desire empecher qu'une application tierce s'authentifie 
avec une empreinte donnee dans un autre environnement d'execution d'applications 
(AEE) dont ('interface avec le module d'abonne (SIM) serait compromise. En effet, si 
Tempreinte A authentifie I'application A aupres du module d'abonne A dans un 
equipement mobile A, il taut eviter qu'une autre application B s'authentifie indument 
avec cette meme empreinte A aupres du module d'abonng B dans i'equipement 
mobile B. 

Selon une autre variante, chaque application (du type Java) est accompagnee de 
deux cryptogrammes: un cryptogramme Java destine a la machine virtuelle (VM) et 
un cryptogramme (CRY) destine au module d'abonne (SIM). Ces deux 
cryptogrammes comprennent entre autre la meme empreinte duplication (ici 
appelee FIN2) qui est cede du code de I'application Java. Ainsi, lorsque le module 
d'abonne (SIM) doit verifier le cryptogramme (CRY) d'une application, il attend de la 
machine virtuelle (VM) I'empreinte (FIN2) assoctee a I'application (APP) en question 
qu'elle aura forcement calculee auparavant. L'empreinte de I'application est 
transmise par l'6quipement mobile (CB) au module d'abonne (SIM). Cette empreinte 
ne provient pas du serveur de controle, elle est calculee par Tenvironnement 
d'execution d'applications (AEE) de I'equipement mobile (CB) apres le 
telechargement de I'application (APP). Par centre, I'equipement mobile (CB) 
transmet le cryptogramme (CRY) prealablement charge en sus de I'application 
depuis le serveur de controle au module d'abonng. Ainsi, ce dernier peut verifier 
I'empreinte regue par comparaison. L'equipement mobile (CB) ne peut pas tricher 
tant qu'il ne connaft pas I'empreinte attendue par le module d'abonne (SIM); le cas 
echeant, cela necessiterait de rendre la fonction de calcul de Tempreinte, 
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habituellement une fonctlon de hachage, r6versible ou de trouver une autre 
empreinte dormant le meme cryptogramme (CRY) ce qui estquasiment impossible. 

La figure 1b montre le processus de verification du cryptogramme (CRY) qui peut 
s'effectuer sort rgguli&rement, par exempte avant chaque sollicitation de I'application 
5 (APP) concemee, sort, de preference, une seule fois avant son installation ou avant 
sa premiere utilisation. Si le cryptogramme (CRY) est valide, le module d'abonnS 
(SIM) transmet un message d'acceptation (OK) a I'environnement d'execution (AEE). 
L'application (APP) peut alors adresser ses requetes ou commandes (CMD) au 
module d'abonne (SIM) via I'environnement d'execution (AEE) et utiliser les 
10 ressources (RES) du module d'abonne (SIM). Ce dernier accepte les commandes 
(CMD) en transmettant les reponses (RSP) adequates a I'application (APP) via 
I'environnement d'execution (AEE), voir figure 1c. 

Dans le cas d'un cryptogramme (CRY) non valide, le module d'abonne (SIM) 
transmet un message de refus (NOK) & I'environnement d'execution (AEE). Dans un 
15 tel cas I'environnement d'execution (AEE) peut sort annuler le processus 
d'installation de ('application (APP), soit I'application (APP) est installee et ses 
requetes ou ses commandes (CMD) adressees au module d'abonne (SIM) via 
renvironnement d'execution (AEE) resteront sans r6ponse (RSP) et les ressources 
(RES) du module d'abonne (SIM) ne pourront etre utilisees. 

20 Dans les deux cas d'acceptation et de refus (OK et NOK) I'environnement 
d'execution d'application (AEE) peut relayer la r6ponse au serveur de controle 
(CSE). Le module d'abonne peut ainsi indirectement renvoyer une confirmation (CF) 
de reception du cryptogramme (CRY) au serveur de controle (CSE) et permettre un 
controle de bout en bout de I'operation, voir figure 1b. La confirmation (CF) 

25 comprend au moins un code de succes ou d'erreur de I'opSration ainsi qu'un 
compteur servant a la protection contre des attaques par repetition. Ce message 
permet aussi au serveur de controle (CSE) de tenir £ jour le compteur associ6 au 
module d'abonne (SIM). 
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Selon le second mode de realisation illustr6 par les figures 2a, 2b, 2c, I'application 
(APP) est telechargee seuie, apres identification (ID) de l'6quipement mobile (CB), 
sans cryptogramme (CRY), voir figure 2a. 

Lors du processus de verification, figure 2b, I'application (APP) sollicite, lore de son 
5 lancement par I'utilisateur, un cryptogramme (CRY) comprenant les droits 
d'utilisation de ressources (RES) pour ladite application. Ce cryptogramme (CRY) 
est telecharge, depuis le serveur (CSE) de controle, directement par I'application 
(APP) qui ie transmet au module d'abonne (SIM) via I'environnement d'execution 
(AEE). Le module d'abonne (SIM) transmet une confirmation (CF) de reception du 
1 0 cryptogramme (CRY) au serveur (CSE), par le biais de I'application (APP) et non par 
le biais de I'environnement d'execution (AEE) comme dans le cas du premier mode 
de realisation. Dans ce mode, I'environnement d'execution (AEE) ne joue qu'un role 
de relais entre I'application (APP) et le module d'abonnd (SIM). 

Le processus d'execution de I'application (APP) apr&s verification du cryptogramme 
15 (CRY), voir figure 2c, se deroule de la meme maniere que dans le premier mode 
illustre par la figure 1c et decrit plus haut. 

Les figures 3a, 3b, 3c montrent une troisieme variante ou I'application APP est 
telecharg6e seuie, apr§s identification (ID) de I'equipement mobile (CB), depuis le 
serveur de controle (CSE) ou depuis un serveur intermediaire de teiechargement 

20 d'applications (APP) voir figure 3a. Lors du processus de verification (figure 3b), 
I'application charge le cryptogramme (CRY) et I'empreinte (FIN2) directement a 
partir du serveur (CSE) ou depuis un serveur intermediaire de teiechargement 
d'applications (APP). Dans ce cas, a la difference des deux variantes precedentes, 
I'envinonnement d'application (AEE) ne calcule plus I'empreinte (FIN2) qui est 

25 calculee par une unite externe soit par le serveur de controle CSE, sort par un 
serveur intermediaire de teiechargement d'applications (APP). 

Le processus d'execution de I'application (APP) apres verification du cryptogramme 
(CRY), voir figure 3c, se deroule de la meme maniere que dans les deux modes 
precedents illustres par les figures 1c et 2c. 
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Ce troisieme mode de realisation peut dtre prefere car son avantage est de ne 
demander aucune modification de I'environnement d'execution (AEE) tel qu'il est 
defini actuellement pour les applications Java installees dans les telephones 
mobiles, c'est-a-dire qu'une modification des normes existantes n'est pas 
5 necessaire. 

De plus, la contrainte de la premiere variante voulant que les deux cryptogrammes 
utilisent la meme empreinte tombe etant donne que les processus de verification du 
cryptogramme (CRY) et celui de Installation de I'application sont totalement 
independants. 

10 Afin de personnaliser les empreintes calculees sur les applications, une possibility 
consiste d ajouter au code de I'application, avant son chargement dans I'equipement 
mobile, une donnee differente pour chaque equipement mobile. Ainsi, lorsque 
I'empreinte est calculee par I'environnement duplication de I'equipement mobile, 
cette empreinte est unique et ne peut servir d un autre equipement mobile. Le 

15 cryptogramme va bien entendu etre calcule par le serveur de controle sur la base 
des donnees d'origine de I'application et de cette donnee unique. 

Dans une variante de I'invention, I'equipement mobile peut etre remplace par un 
equipement non mobile tel qu'un decodeur de television a peage ou un ordinateur. 
Des applications peuvent etre telechargees dans Tequipement a partir d'un serveur 
20 via un reseau de telecommunications. Un cryptogramme associe d I'application est 
stocke dans le module de securite et verifie lors de la mise en service ou lore de 
chaque d6marrage d'une application. Le resultat de cette verification conditionne le 
fonctionnement de I'application en liberant ou en bloquant des ressources dans le 
module de securite. 



25 
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REVENDI CATIONS 

1. Methods d'authentiftcation d'au moins una application (APP) fonctionnant 
dans un equipement (CB) connecte par un reseau (NET) a un serveur de controle 
(CSE), ledit equipement (CB) etant looalement connecte d un module de s6curit6 
(SIM), ladite application (APP) est chargee et/ou executee au moyen d'un 
environnement d*ex6cution d'applications (AEE) de I'dquipement (CB) et utilise des 
ressources (RES) stockees dans le module de securite (SIM), comprenant les 
etapes preliminaires suivantes: 

reception de donnees comprenant au moins I'identifiant (IMEISV) de 
I'equipement (CB) et I'identifiant (IMSI) du module de s6curit6 (SIM), via le 
r6seau (NET), par le serveur de controle (CSE) 

analyse et verification par le serveur de contrdle (CSE) desdites donnees, 
g6neration d'un cryptogramme (CRY) comprenant une empreinte (FIN1) de 
('application (APP), des donnges identifiant I'equipement (CB) et le module de 
securite (SIM) et des instructions (INSURES) destinees audit module, 
transmission dudit cryptogramme (CRY), via le reseau (NET) et Tequipement 
(CB), au module de securite (SIM), 
- verification de ('application (APP) en comparant Tempreinte (FIN1) extraite du 
cryptogramme (CRY) re^j avec une empreinte (FIN2) d6termin6e par le 
module de securite (SIM), 
ladite methode est caracterisee en ce que, lors de I'iniUalisation et/ou de I'activation 
de ('application (APP), le module de securite (SIM) execute les instructions 
(INSURES) extraites du cryptogramme (CRY) et lib&re, respectivement bloque 
Faeces a certaines ressources (RES) dudit module de securite (SIM) en fonction du 
r6sultat de la verification propre a cette application (APP) effectuee prealablement. 

2. Methode selon la revendication 1 caracterisee en ce que i'equipement est un 
equipement mobile (CB) de telephonie mobile. 

3. Methode selon la revendication 1 caracterisee en ce que le reseau (NET) est 
un reseau mobile du type GSM ou GPRS ou UMTS. 
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4. Mgthode selon la revendication 1 ou 2, caracterisee en ce que le module de 
security (SIM) est un module d'abonne insere dans I'equipement mobile (CB) de 
t§l6phonie mobile de type carte SIM. 

5. Methode selon la revendication 1 ou 4 caracterisee en ce que ('identification 
(ID) de rensemble equipement mobile (CB) / module d'abonne (SIM) est effectuee a 
partir de I'identifiant (IMEISV) de I'equipement mobile (CB) et de I'identifiant (IMSI) 
du module d'abonne (SIM) propre a un abonne au reseau (NET). 

6. Methode selon la revendication 1 caracterisee en ce que les instructions 
incluses dans le cryptogramme (CRY) regu par le module de s6curite (SIM) 
conditionnent rutilisation des applications (APP) selon des criteres preetablis par 
I'operateur et/ou le fournisseur d'applications (FA) et/ou I'utilisateur de I'equipement. 

7. Methode selon la revendication 6 caracterisee en ce que les criteres 
d£finissent des limites d'utilisation d'une application (APP) selon des risques 
associes au logiciel de ladite application (APP) ou au materiel de I'equipement (CB) 
que I'operateur desire prendre en compte. 

8. Methode selon la revendication 1 caracterisee en ce que la verification de 
I'application (APP) avec le cryptogramme (CRY) s'effectue lors du premier 
demarrage ou lors de la premiere utilisation de ladite application (APP). 

9. Methode selon la revendication 1 caracterisee en ce que la verification de 
I'application (APP) avec le cryptogramme (CRY) s'effectue p€riodiquement a un 
rythme donne selon des instructions provenant du serveur de controle (CSE). 

10. Methode selon la revendication 1 caracterisee en ce que la verification de 
I'application (APP) avec le cryptogramme (CRY) s'effectue lors de chaque 
demarrage de ladite application (APP) sur I'equipement (CB). 

11. Methode selon la revendication 1 caracterisee en ce que le cryptogramme 
(CRY) est genere a I'aide d'une cle d'encryption asymetrique ou symetrique a partir 
d'un ensemble de donnees contenant, entre autres donn6es, I'identifiant (IMEISV) 
de I'equipement (CB), I'identifiant (IMSI) du module de securite (SIM), un 
identlficateur de I'application (APP), I'empreinte (FIN1) de I'application (APP) 
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calcutee avec une fonction unidirectionnelle de hachage, des identrficateurs 
(RESJD) des ressources du module de s6curite (SIM) et des instructions 
(INSURES) de blocage/Iiberation des ressources (RES) du module de s6curite 
(SIM). 

12. Mdthode selon la revendication 11 caracterisee en ce que le cryptogramme 
(CRY) comprend une variable predictible par le module de s6curite (SIM) dvltant le 
double usage d'un meme cryptogramme (CRY), la valeur de ladite variable etant 
controlee par le module de securite (SIM) par comparaison avec cede d'une valeur 
de reference stock6e dans ledit module et r§gulierement mise a jour. 

13. M6thode selon ia revendication 1 caracterisee en ce que le module de 
securite (SIM) transmet au serveur de controle (CSE), via I'equipement (CB) et le 
reseau (NET), un message de confirmation (CF) lorsque ledit module de s6curite 
(SIM) a accepte ou refuse un cryptogramme (CRY) d'une application (APP). 

14. Mdthode selon la revendication 1 caracterisee en ce que le cryptogramme 
(CRY) est transmis au module de securite (SIM) en meme temps que I'application 
(APP) est charg6e dans T6quipement (CB) via I'environnement d'execution des 
applications (AEE). 

15. Methode selon la revendication 1 caracterisee en ce que I'application (APP), 
une fois charg^e dans I'equipement (CB) depuis le serveur (CSE) de controle via le 
r6seau (NET), sollicite un cryptogramme (CRY) au serveur (CSE) lors de son 
initialisation et transmet ledit cryptogramme (CRY) au module de s6curite (SIM), le 
message de confirmation (CF) d'acceptation ou de refus du cryptogramme (CRY) 
etant transmis par le module de securite (SIM) au serveur via Implication (APP). 

16. Mgthode selon la revendication 1 , caracterisee en ce que I'equipement est un 
decodeur de television a pdage ou un ordinateur auquel est connecte le module de 
securite. 

17. Module de securite comprenant des ressources (RES) destin§es a etre 
localement accedees par au moins une application (APP) installee dans un 
6quipement (CB) relie a un reseau (NET), ledit equipement (CB) comprenant des 
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moyens de lecture et de transmission de donnees comprenant au moins I'ident'rfiant 
(IMEISV) de I'equipement (CB) et ridentifiant (IMSI) du module de securite (SIM), 
ledlt module est caracterise en ce qu'il comprend des moyens de reception, de 
stockage et d'analyse d'un cryptogramme (CRY) contenant entre autre donn6es une 
empreinte (FIN1) de ladite application (APP) et des instructions (INSURES), des 
moyens de verification de ladite application (APP) et des moyens d'extraction et 
d'execution des instructions (INSURES) contenues dans le cryptogramme (CRY) 
libgrant ou bloquant certaines ressources (RES) selon le resultat de la verification 
de I'application (APP). 

18. Module de securite selon la revendication 17, caracterise en ce qu'il est du 
type "module d'abonne" ou "carte SIM" destine d Stre relI6 d un equipement mobile. 
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